Project ABC—Development Case

This is an example of what a development case may look like. There is no point in restating information already in the process. What you have to describe are the deviations from the process. You may put together a Development Case that contains a small description of the process. However, the problem with that kind of document is that they tend to grow forever, until they're the size of the process handbook!

This example is intended to give you an idea about how a development case would look for a small project, let's say a commercial information system.

For more information about the Development Case, its contents, and outline, see Artifact: Development Case.

Topics

• Introduction
  • Revision History
  • Purpose
  • Definitions, Acronyms and Abbreviations
  • References
• Overview of the Development Case
  • Lifecycle Model
  • Core Workflows
  • Core Workflow Configuration
  • Artifact Classification
  • Review Procedures
  • Sample Iteration Plans
• Core Workflows
  • Business Modeling
  • Requirements
  • Analysis & Design
  • Implementation
  • Testing
  • Deployment
  • Configuration & Change Management
  • Project Management
  • Environment
• Workers

Introduction (to top)

Revision History (to top)

Purpose (to top)

The purpose of the document is to describe the development process for the project ABC.

Definitions, Acronyms, and Abbreviations (to top)

Not applicable.

References (to top)

Not applicable.

Overview of the Development Case (to top)

Lifecycle Model (to top)

See the section titled "Project Plan" in the project's Software Development Plan.

Core Workflows (to top)

The development-case example presented here takes you through all nine core workflows: Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, and Environment.

Core Workflow Configuration  (to top)

The purpose of this section is to explain how the core workflow configuration works. This includes the purpose of the different tables and sections that describe each core workflow in the section titled "Core Workflows".

Section: "Workflow"

This section details any changes made to the structure of the workflow itself. Typical changes include the addition of activities to describe company-specific ways of working or the removal of activities from the workflow.

Section: "Artifacts"

The section describes, in a table, how the artifact will be used. Additional 'local' artifacts can be added to the table as needed. 

Section: "Notes on Artifacts"

This section has three main purposes: 

• It contains a list all artifacts you Won't use and the motives behind your decision not to use them. 
• It contains a reference to the project's Configuration Management (CM) Plan, which describes the configuration management strategy used when working on these artifacts. The CM Plan allows developers to answer questions such as: 
  • When do I release my artifact? 
  • Where do I put my newly created or modified artifact?
  • Where do I find existing artifacts for the project?
• If the development case is an organization-level development case, this is where you add notes on what each project needs to consider when they decide what to do with the artifact. Use the predefined table below as a starting point. 

Section: "Reports"

This section lists the reports to be used and additional 'local' reports can be added to the table as needed.

Section: "Notes on the Reports"

This section has two main purposes. First, it lists all reports that the project has decided it Won't use, and the motives behind its decision not to use them. Secondly, if the development case is a an organization-level use case, this is where to add notes on what each project needs to consider when they decide what to do with the report.

Section: "Additional Review Procedures"

This section captures any additional review procedures required for the artifacts used in the workflow. These supplement the general review procedures described in the "Overview" section of the Development Case.

Section: "Other Issues"

This section captures any outstanding issues with the workflow's configuration. This section can be used as an Issues List while building the development case.

Artifact Classification (to top)

An artifact is a deliverable of the process. It is often developed within one core workflow, although there are exceptions. The artifacts are organized in the workflow where it's created. To describe how an artifact will be used, consider the following classification scheme and see Guidelines: Classifying Artifacts for details:  

• Must

• Should

• Could

• Won't

Review Procedures (to top)

The project uses the following review levels: 

• Formal-External
• Formal-Internal
• Informal
• None

For details, see Guidelines: Review Levels.

Sample Iteration Plans  (to top)

Inception Phase

• Sample Iteration Plan: Inception Phase

Elaboration Phase

To be defined later in the project.

Construction Phase

To be defined later in the project.

Transition Phase

To be defined later in the project.

Core Workflows (to top)

Business Modeling (to top)

Workflow

Follow the Domain Modeling workflow detail only. See Business Modeling: Overview.

Artifacts

Notes on the Artifacts

See the project's Configuration Management Plan for information on how the artifacts are 
configuration-managed.

The project decided to only perform domain modeling, which means that the following artifacts will not be developed: Business Actor, Business Architecture Document, Business Rules, Business Use Case, Business Use-Case Model, Business Vision, Business Worker, Organization Unit, and Supplementary Business Specification.

Reports

Requirements (to top)

Workflow

No changes. For details see the Requirements Overview.

Artifacts

Notes on the Artifacts

See the project's Configuration Management Plan for information about how the artifacts are 
configuration-managed.

Reports

Analysis & Design (to top)

Workflow

A real-time application is not being developed, therefore the Capsule Designer worker and the activity Capsule Design are excluded. For details on the workflow, see the Analysis & Design Overview. 

Artifacts

Notes on the Artifacts

The project is not developing a real-time product, which means that the following artifacts will not developed: Capsule, Event, Protocol, and Signal.

The project decided not to keep an analysis model, which means that the following artifacts will not be developed: Analysis Class and Analysis Model. 

Reports

Implementation (to top)

Workflow

No changes in the workflow. For details see the Implementation Overview.

Artifacts

Additional Review Procedures

Informal code reviews are performed. 

Testing (to top)

Workflow

No formal performance test is done, otherwise the workflow is followed unchanged. For details on the process, see the Test: Overview.

Artifacts

Notes on the Artifacts

No Workload Analysis Document is developed.

Additional Review Procedures

• Test cases—informally approved by the system testers.
• The system testers decide if the test criteria for an iteration is fulfilled.
• The customer approves the final iteration.

Deployment (to top)

Workflow

A previously existing deployment workflow was adapted to use the artifacts suggested in the Rational Unified Process. An exception is the Course Material artifact, which is excluded because no formal training is produced for our product.

Artifacts

Notes on the Artifacts

No Training Materials are developed because the product does not require formal training. 

Reports

Configuration & Change Management (to top)

Workflow

No changes in the workflow. For details on the process, see the Configuration & Change Management: Overview.

Artifacts

Project Management (to top)

Workflow

No changes to the workflow. For details, see Project Management: Overview.

Artifacts

Notes on the Artifacts

The artifact Work Order won't be used. 

Environment (to top)

Workflow

No changes in the workflow. For details on the process, see the Environment: Overview.

Artifacts

Workers (to top)

Not applicable.

Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Rational Unified Process